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INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the  Ada 
Validation  Procedures  [Pro90]  against  the  Ada  Standard  [Ada83]  using  the 
current  Ada  Compiler  Validation  Capability  (ACVC) .  This  Validation  Summary 
Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada  implementation. 
For  any  technical  terms  used  in  this  report,  the  reader  is  referred  to 
[Pro90].  A  detailed  description  of  the  ACVC  may  be  found  in  the  current 
ACVC  User's  Guide  [UG89]. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  public  disclosure  of  this  report. 
In  the  United  States,  this  is  provided  in  accordance  with  the  "Freedom  of 
Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply 
only  to  the  computers,  operating  systems,  and  compiler  versions  identified 
in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  and  complete,  or  that  the  subject  implementation  has  no 
nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  public  from  the  AVF  which  performed  this 
validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  which  performed  this  validation  or  to: 

Ada  Validation  Organization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 


1.2  REFERENCES 

(Ada83]  Reference  Manual  for  the  Ada  Programming  Language. 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 

[Pro90]  Ada  Compiler  Validation  Procedures.  Version  2.1,  Ada  Joint 
Program  Office,  August  1990. 

[UG89]  Ada  Compiler  Validation  Capability  User's  Guide.  21  June  1989. 
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1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes:  A, 
B,  C,  0,  E,  and  L.  The  first  letter  of  a  test  name  identifies  the  class  to 
which  it  belongs.  Class  A,  C,  0,  and  E  tests  are  executable.  Class  B  and 
class  L  testa  are  expected  to  produce  errors  at  compile  time  and  link  time, 
respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a 
PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the  result  when  they 
are  executed.  Three  Ada  library  units,  the  packages  REPORT  and  SPPRT13, 
and  the  procedure  CHECK  FILE  are  used  for  this  purpose.  The  package  REPORT 
also  provides  a  set  of  Identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  by  many  testa  for  Chapter  13  of  the 
Ada  Standard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents  of 
text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the  Ada 
Standard.  The  operation  of  REPORT  and  CHECK_F1LE  is  checked  by  a  set  of 
executable  tests.  If  these  units  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  B  testa  check  that  a  compiler  detects  illegal  language  usage.  Class 
B  tests  are  not  executable.  Each  test  in  this  class  is  compiled  and  the 
resulting  compilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  which  must  not  be  flagged  illegal  by  the  compiler.  This  behavior  is 
also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects  violation 
of  the  Ada  Standard  involving  multiple,  separately  compiled  units.  Errors 
are  expected  at  link  time,  and  execution  is  attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by 
implementation-specific  values  —  for  example,  the  largest  integer.  A  list 
of  the  values  used  for  this  implementation  is  provided  in  Appendix  A.  In 
addition  to  these  anticipated  test  modifications,  additional  changes  may  be 
required  to  remove  unforeseen  conflicts  between  the  tests  and 
implementation-dependent  characteristics.  The  modifications  required  for 
this  implementation  are  described  in  section  2.3. 

For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the 
AVF.  This  customization  consists  of  making  the  modifications  described  in 
the  preceding  paragraph,  removing  withdrawn  tests  (see  section  2.1),  and 
possibly  removing  some  inapplicable  tests  (see  section  2.2  and  [UG89]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of 
the  customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 


Ada  Compiler  The  software  and  any  needed  hardware  that  have  to  be  added 
to  a  given  host  and  target  computer  system  to  allow 
transformation  of  Ada  programs  into  executable  form  and 
execution  thereof. 


Ada  Compiler 
Validation 
Capability 
(ACVC) 


The  means  for  testing  compliance  of  Ada  implementations, 
consisting  of  the  test  suite,  the  support  programs,  the  ACVC 
user's  guide  and  the  template  for  the  validation  summary 
report . 


Ada  An  Ada  compiler  with  its  host  computer  system  and  its 

Implementation  teurget  computer  system. 


Ada  Joint  The  part  of  the  certification  body  which  provides  policy  and 
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guidance  for  the  Ada  certification  system. 


The  part  of  the  certification  body  which  carries  out  the 
procedures  required  to  establish  the  compliance  of  an  Ada 
implementation. 

The  part  of  the  certification  body  that  provides  technical 
guidance  for  operations  of  the  Ada  certification  system. 


The  ability  of  the  implementation  to  pass  an  ACVC  version. 


A  functional  unit,  consisting  of  one  or  more  computers  and 
associated  software,  that  uses  common  storage  for  all  or 
part  of  a  program  and  also  for  all  or  part  of  the  data 
necessary  for  the  execution  of  the  program;  executes 
user-written  or  user-designated  programs;  performs 
user-designated  data  manipulation,  including  arithmetic 
operations  and  logic  operations;  and  that  can  execute 
programs  that  modify  themselves  during  execution.  A 
computer  system  may  be  a  stand-alone  unit  or  may  consist  of 
several  inter-connected  units. 

Fulfillment  by  a  product,  process,  or  service  of  all 
requirements  specified. 

An  individual  or  corporate  entity  who  enters  into  an 
agreement  with  an  AVF  which  specifies  the  terms  and 
conditions  for  AVF  services  (of  any  kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity 
is  realized  or  attainable  on  the  Ada  implementation  for 
which  validation  status  is  realized. 

A  computer  system  where  Ada  source  programs  are  transformed 
into  executable  form. 

A  test  that  contains  one  or  more  test  objectives  found  to  be 
irrelevant  for  the  given  Ada  implementation. 

International  Organization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Manual,  published  as 
ANSI/MIL-STD-1815A-1983  and  ISO  8652-1987.  Citations  from 
the  LRM  take  the  form  '*<section>.<subsection>:<paragraph>. " 

Software  that  controls  the  execution  of  programs  and  that 
provides  services  such  as  resource  allocation,  scheduling, 
input/output  control,  and  data  management.  Usually, 
operating  systems  are  predominantly  software,  but  partial  or 
complete  hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada  programs 
are  executed. 


The  compiler  of  a  validated  Ada  implementation. 

An  Ada  implementation  that  has  been  validated  successfully 
either  by  AVF  testing  or  by  registration  [Pro90]. 
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Validation 


Withdrawn 

test 


The  process  of  checking  the  conformity  of  an  Ada  compiler  to 
the  Ada  programming  language  and  of  issuing  a  certificate 
for  this  implementation. 

A  test  found  to  be  incorrect  and  not  used  in  conformity 
testing.  A  test  may  be  incorrect  because  it  has  an  invalid 
teat  objective,  fails  to  meet  its  test  objective,  or 
contains  erroneous  or  illegal  use  of  the  Ada  programming 
language. 
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CHAPTER  2 


IMPLEMENTATION  DEPENDENCIES 


2.1  WITHDRAWN  TESTS 


The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for 
withdrawing  each  test  is  available  from  either  the  AVO  or  the  AVF.  The 
publication  date  for  this  list  of  withdrawn  tests  is  02  August  1991. 


E28005C 

C35508M 

C45114A 

C46022A 

B83022H 

B85001L 

CB7001A 

BC3009B 

CD2A23E 

BD3006A 

CD4024D 

CD7005E 

A07206A 

CE2107I 

CE3111C 

CE3607C 


B28006C 

C35508N 

C4S346A 

B49008A 

B83025B 

C86001F 

CB7001B 

B01B02B 

CD2A32A 

BD4008A 

CD4031A 

AD7006A 

BD8002A 

CE2117A 

CE3116A 

CE3607D 


C32203A 

C35702A 

C45612A 

B490Q8B 

B830250 

C94021A 

CB7004A 

BD1B06A 

C02A41A 

CD4022A 

CD40S1D 

C070Q6E 

BD8004C 

CE2117B 

CE3118A 

CE3812A 


C34006D 

C35702B 

C45612B 

A74006A 

B83026B 

C97116A 

CC1223A 

AD1B08A 

CD2A41E 

CD4022D 

CD5111A 

AD7201A 

CD9005A 

CE2119B 

CE3411B 

CE3814A 


C35508I 

B41308B 

C45612C 

C74308A 

C83026A 

C98003B 

BC1226A 

BD2A02A 

CD2A87A 

CD4024B 

CD7004C 

AD7201B 

CD9005B 

CE2205B 

CE3412B 

CE3902B 


C35508J 

C43004A 

C45651A 

B83022B 

C83041A 

BA2011A 

CC1226B 

CD2A21E 

CD2B15C 

CD4024C 

ED7005D 

CD7204B 

CDA201E 

CE2405A 

CE3607B 


2 . 2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are  irrelevant 
for  a  given  Ada  implementation.  Reasons  for  a  test's  inapplicability  may  be 
supported  by  documents  issued  by  the  ISO  and  the  AJPO  known  as  Ada 
Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For  this 
implementation,  the  following  tests  were  determined  to  be  inapplicable  for 
the  reasons  indicated;  references  to  Ada  Commentaries  are  included  as 
appropriate. 


The  following  327  tests  have  floating-point  type  declarations 
requiring  more  digits  than  SYSTEM. MAX_DIG ITS: 


C24113C. .Y 
C35706C. .Y 
C35708C. .Y 
C45241C. .Y 
C45421C. .Y 
C4S524C. .Z 
C45641C. .Y 


(23  tests) 
(23  tests) 
(23  tests) 
(23  tests) 
(23  tests) 
(24  tests) 
(23  tests) 


C35705C..Y 
C35707C. .Y 
C35802C. .V 
C45321C. .Y 
C4S521C. .Z 
C45621C. .Z 
C46012C. .Z 


(23  tests) 
(23  tests) 
(24  tests) 
(23  tests) 
(24  tests) 
(24  tests) 
(24  tests) 
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The  following  21  tests  check  for  the  predefined  type  SHORT  INTEGER; 
for  this  implementation,  there  is  no  such  type:  ~ 


C35404B 

C45412B 

C45611B 

B52004E 

CD7101E 


B3610SC 

C4S502B 

C45613B 

C55B07B 


C45231B 

C45503B 

C45614B 

BS5B09D 


C45304B 

C45504B 

C45631B 

B86001V 


C45411B 

C45504E 

C45632B 

C86006D 


The  following  20  tests  check  for  the  predefined  type  LONG_INTEGER;  for 
this  implementation,  there  is  no  such  type: 


C35404C 

C45502C 

C45613C 

C55B07A 


C45231C 

C45503C 

C45614C 

B55B09C 


C45304C 

C45504C 

C45631C 

B86001W 


C45411C 

C45504F 

C45632C 

C86006C 


C45412C 

C45611C 

B52004D 

CD7101F 


C354040,  C452310,  B86001X,  C86006E,  and  CD7101G  check  for  a  predefined 
integer  type  with  a  name  other  than  INTEGER,  LONG_INTEGER,  or 
SHORT_INTEGER;  for  this  implementation,  there  is  no  such  type. 


"0357138,  C4S423B,  B86001T,  and  C86006H  check  for  the  predefined  type 

SHORT_FLOAT;  for  this  implementation,  there  is  no  such  type. 


C35713C,  B86001U,  and  C86006G  check  for  the  predefined  type 
LONG_FLOAT;  for  this  implementation,  there  is  no  such  type. 

C35713D  and  B86001Z  check  for  a  predefined  floating-point  type  with 
a  name  other  than  FLOAT,  LONG_FLOAT,  or  SHORT_FLOAT;  for  this 
implementation,  there  is  no  such  t^e. 


A35801E  checks  that  FLOAT 'FIRST. .FLOAT 'LAST  may  be  used  as  a  range 
constraint  in  a  floating-point  type  declaration;  for  this 
implementation,  that  range  exceeds  the  range  of  safe  numbers  of  the 
largest  predefined  floating-point  type  and  must  be  rejected.  (See 
section  2.3. ) 


C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations  for 
types  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or  greater;  for  this 
implementation,  MAX_MANTISSA  is  l^s  than  47. 

C45536A,  C46013B,  C46031B,  C46033B,  and  C46034B  contain  length  clauses 
that  specify  values  for  'SMALL  that  are  not  powers  of  two  or  ten;  this 
implementation  does  not  support  such  values  for  'SMALL. 

C45624A..B  (2  tests)  check  that  the  proper  exception  is  raised  if 
MACHINE_OVERFLOWS  is  FALSE  for  floating  point  types  and  the  results  of 
various  floating-point  operations  lie  outside  the  range  of  the  base 
type;  for  this  implementation,  MACHINE__0VERFL0WS  is  TRUE. 

D64005F. .G  use  17  levels  of  recursive  procedure  calls  nesting;  this 
level  of  nesting  for  procedure  calls  exceeds  the  capacity  of  the 
compiler. 


B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than  type 
DURATION;  for  this  implementation,  there  is  no  such  type. 

CA2009A,  CA2009C..D  (2  tests),  CA2009F  and  BC3009C  were  graded 
inapplicable  by  Evaluation  Modification  as  directed  by  the  AVO.  These 
tests  instantiate  generic  units  before  those  units'  bodies  are 
compiled;  this  implementation  creates  dependences  as  allowed  by  AI- 
00408  &  AI-00506  such  that  the  compilation  of  the  generic  unit  bodies 
makes  the  instantiating  units  obsolete,  and  the  objectives  of  these 
tests  cannot  be  met. 
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CD1009C  checks  whether  a  length  clause  can  specify  a  non-default  size 
for  a  floating-point  type;  this  implementation  does  not  support  such 
sizes. 

CD2A53A  checks  operations  of  a  fixed-point  type  for  which  a  length 
clause  specifies  a  power-of-ten  TYPE 'SMALL;  this  implementation  does 
not  support  decimal  'SMALLs.  (See  section  2.3.) 

CD2A84A,  CD2A84E,  CD2A84I..J  (2  tests),  and  CD2A840  use  length  clauses 
to  specify  non-default  sizes  for  access  types;  this  implementation 
does  not  support  such  sizes. 

CD2B15B  checks  that  STORAGE_ERROR  is  raised  when  the  storage  size 
specified  for  a  collection  is  too  small  to  hold  a  single  value  of  the 
designated  type;  this  implementation  allocates  more  space  than  was 
specified  by  the  length  clause,  as  allowed  by  AI-00558. 

AE2101C  and  EE2201D..E  (2  tests)  use  instantiations  of  package 
SEQUENTIAL_IO  with  unconstrained  array  types  and  record  types  with 
discriminants  without  defaults;  these  instantiations  are  rejected  by 
this  compiler. 

AE2101H,  EE2401D,  and  EE2401G  use  instantiations  of  package  DIRECT_IO 
with  unconstrained  array  types  and  record  types  with  discriminants 
without  defaults;  these  instantiations  are  rejected  by  this  compiler. 

The  following  264  tests  check  operations  on  sequential,  text,  and 
direct  access  files;  this  implementation  does  not  support  external 
files: 


CE2102A. .C 

(3) 

CE2102G. .H 

(2) 

CE2102K 

CE2102N. .Y 

(12) 

CE2103C. .D 

(2) 

CE2104A. .D 

(4) 

CE2105A. .B 

(2) 

CE2106A. .B 

(2) 

CE2107A. .H 

(8) 

CE2107L 

CE2108A. .H 

(8) 

CE2109A. .C 

(3) 

CE2110A. .D 

(4) 

CE2111A. .1 

(9) 

CE2115A. .B 

(2) 

CE2120A. .B 

(2) 

CE2201A. .C 

(3) 

EE2201D. .E 

(2) 

CE2201F. .N 

(9) 

CE2203A 

CE2204A. .D 

(4) 

CE2205A 

CE2206A 

CE2208B 

CE2401A. .C 

(3) 

EE2401D 

CE2401E. .F 

(2) 

EE2401G 

CE2401H. .L 

(5) 

CE2403A 

CE2404A. .B 

(2) 

CE2405B 

CE2406A 

CE2407A. .B 

(2) 

CE2408A. .B 

(2) 

CE2409A. .B 

(2) 

CE2410A. .B 

(2) 

CE2411A 

CE3102A. .C 

(3) 

CE3102F. .H 

(3) 

CE3102J. .K 

(2) 

CE3103A 

CE3104A. .C 

(3) 

CE3106A. .B 

(2) 

CE3107B 

CE3108A. .B 

(2) 

CE3109A 

CE3110A 

CE3111A. .B 

(2) 

CE3111D. .E 

(2) 

CE3112A. .D 

(4) 

CE3114A. .B 

(2) 

CE3115A 

CE3119A 

EE3203A 

EE3204A 

CE3207A 

CE3208A 

CE3301A 

EE3301B 

CE3302A 

CE3304A 

CE3305A 

CE3401A 

CE3402A 

EE3402B 

CE3402C. .D 

(2) 

CE3403A. .C 

(3) 

CE3403E. .F 

(2) 

CE3404B. .D 

(3) 

CE3405A 

EE3405B 

CE3405C. .D 

(2) 

CE3406A. .D 

(4) 

CE3407A. .C 

(3) 

CE3408A. .C 

(3) 

CE3409A 

CE3409C. .E 

(3) 

EE3409F 

CE3410A 

CE3410C. .E 

(3) 

EE3410F 

CE3411A 

CE3411C 

CE3412A 

EE3412C 

CE3413A. .C 

(3) 

CE3414A 

CE3602A. .D 

(4) 

CE3603A 

CE3604A. .B 

(2) 

CE3605A. .E 

(5) 

CE3606A. .B 

(2) 

CE3704A. .F 

(6) 

CE3704M. .O 

(3) 

CE3705A. .E 

(5) 

CE3706D 

CE3706F. .G 

(2) 

CE3804A. .P 

(16) 

CE3805A. .B 

(2) 

CE3806A. .B 

(2) 

CE3806D. .E 

(2) 

CE3806G. .H 

(2) 

CE3904A. .B 

(2) 

CE3905A. .C 

(3) 

CE3905L 

CE3906A. .C 

(3) 

CE3906E. .F 

(2) 

CE2103A,  CE2103B,  and  CE3107A  expect  that  NAME_ERROR  is  raised  when  an 
attempt  is  made  to  create  a  file  with  an  illegal  neutie;  this 
implementation  does  not  support  the  creation  of  external  files  and  so 
raises  USE  ERROR. 
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2.3  TEST  MODIFICATIONS 

Modifications  (see  Section  1.3)  were  required  for  100  tests. 


The  following  tests  were  split  into  two  or  more  tests  because  this 
implementation  did  not  report  the  violations  of  the  Ada  Standard  in  the 
way  expected  by  the  original  tests. 


B22003A 

B33205A 

B37201A 

B3800SA 

B38103C 

B48002B 

B49005A 

B4A010C 

B59001C 

B67001D 

B85008G 

B95031A 

BC1206A 

BD4003A 


B24007A 

B35701A 

B37202A 

B38C08B 

B38103D 

B48002D 

B49006A 

B54A20A 

B59001I 

B74103E 

B85008H 

B95074E 

BC2001E 

B04006A 


B24009A 

B36171A 

B37203A 

B38009A 

B38103E 

B48002E 

B49006B 

B54A25A 

B62006C 

B74104A 

B91004A 

BAIOOIA 

BC3005B 

BD8003A 


B25002B 

B36201A 

B37302A 

B38009B 

B43202C 

B48002G 

B49007A 

B58002A 

B67001A 

B74307B 

B91005A 

BC1002A 

BD2A06A 


B32201A 

B37101A 

B38003A 

B38103A 

B44002A 

B48003E 

B49007B 

B58002B 

B67001B 

B83E01A 

B95003A 

BC1109A 

BD2B03A 


B33204A 

B37102A 

B38003B 

B38103B 

B48002A 

B49003A 

B49009A 

B59001A 

B67001C 

B85007C 

B95007B 

BC1109C 

BD2003A 


E28002B  was  graded  passed  by  Processing  Modification  as  directed  by  the 
AVO.  This  test  checks  that  pragmas  may  have  unresolvable  arg\iments,  and 
it  includes  a  check  that  pragma  LIST  has  the  required  effect;  but,  for 
this  implementation,  pragma  LIST  has  no  effect  if  the  compilation 
results  in  errors  or  warnings,  which  is  the  case  when  the  test  is 
processed  without  modification.  This  test  was  also  processed  with  the 
pragmas  at  lines  46,  58,  70  and  71  commented  out  so  that  correct 
operation  of  pragma  LIST  was  demonstrated. 

C34003A  was  graded  passed  by  Evaluation  Modification  as  directed  by  the 
AVO.  This  test  checks  that  required  predefined  operations  are  declared 
for  floating-point  types,  and  it  includes  a  check  for  'BASE 'SIZE  for 
a  floating-point  type.  This  implementation's  target  architecture  uses 
an  effective  word  size  of  24  bits  for  all  but  floating-point  objects, 
which  occupy  an  additional  8  bits  (for  the  sign  and  exponent)  which  are 
inaccessible  to  all  but  floating-point  machine  operations.  To 
accommodate  this  unusual  architecture  with  a  normal  storage-allocation 
scheme,  both  SYSTEM. STORAGE_SIZE  and  FLOAT 'BASE' SIZE  are  set  to  24; 
hence,  the  check  for  'BASE 'SIZE  at  line  186  is  failed  (since  the 
additional  8  bits  are  not  counted  in  'SIZE).  The  AVO  accepted  this 
deviation  as  justified  by  the  target  architecture  in  terms  of  AI-00325. 
Thus  the  test  was  graded  passed  given  that  the  only  Report  .Failed 
output  was  (from  line  187): 

"INCORRECT  'BASE 'SIZE" 

A35801E  was  graded  inapplicable  by  Evaluation  Modification  as  directed 
by  the  AVO.  The  compiler  rejects  the  use  of  the  range 
FLOAT 'FIRST. .FLOAT 'LAST  as  the  range  constraint  of  a  floating-point 
type  declaration  because  the  bounds  lie  outside  of  the  range  of  safe 
numbers  (cf.  LRM  3.5.7:12). 

C35902A  was  graded  passed  by  Test  Modification  as  directed  by  the  AVO. 
This  test  checks  that  'SMALL  for  fixed-point  types  has  the  correct 
value.  This  implementation's  SYSTEM. MAX_MANTISSA  »  24,  but  the  test 
declares  a  type  at  line  20  that  requires  25  bits;  the  implementation 
rejects  this  declaration.  This  test  was  modified  by  changing  the  value 
of  the  named  number  at  line  13  (which  is  used  as  delta  for  the  type  at 
line  20)  from  2  **  -24  to  2  **  -23;  i.e.,  line  13'a  declaration  was 
changed  to: 

D  TINY  :  CONSTANT  :»  16#0. 000002/;  —  (2  **  -23) 
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C83030C  and  C86007A  were  graded  passed  by  Test  Modification  as  directed 
by  the  AVO.  These  tests  were  modified  by  inserting  "PRAGMA  ELABORATE 
(REPORT);"  before  the  package  declarations  at  lines  13  and  11, 
respectively.  Without  the  pragma,  the  packages  may  be  elaborated  prior 
to  package  Report's  body,  and  thus  the  packages'  calls  to  function 
REPORT. IDENT_INT  at  lines  14  and  13,  respectively,  will  raise 
PROGRAM_ERROR. 

B83E01B  was  graded  passed  by  Evaluation  Modification  as  directed  by  the 
AVO.  This  test  chec'  i  that  a  generic  subprogram's  formal  parameter 
names  (i.e.  both  generic  and  subprogram  formal  parameter  names)  must 
be  distinct;  the  duplicated  names  within  the  generic  declarations  are 
marked  as  errors,  whereas  their  recurrences  in  the  subprogram  bodies 
are  marked  as  "optional"  errors — except  for  the  case  at  line  122,  which 
is  marked  as  an  error.  This  implementation  does  not  additionally  flag 
the  errors  in  the  bodies  and  thus  the  expected  error  at  line  122  is  not 
flagged.  The  AVO  ruled  that  the  implementation's  behavior  was 
acceptable  and  that  the  test  need  not  be  split  (such  a  split  would 
simply  duplicate  the  case  in  B83E01A  at  line  15). 

CA2009A,  CA2009C..D  (2  tests),  CA2009F  and  BC3009C  were  graded 
inapplicable  by  Evaluation  Modification  as  directed  by  the  AVO.  These 
tests  instantiate  generic  units  before  those  units'  bodies  are 
compiled;  this  implementation  creates  dependences  as  allowed  by  AI- 
00408  &  AI-00506  such  that  the  compilation  of  the  generic  unit  bodies 
makes  the  instantiating  units  obsolete,  and  the  objectives  of  these 
tests  cannot  be  met. 

BC3204C  and  BC3205D  were  graded  passed  by  Processing  Modification  as 
directed  by  the  AVO.  These  tests  check  that  instantiations  of  generic 
units  with  unconstrained  types  as  generic  actual  parameters  are  illegal 
if  the  generic  bodies  contain  uses  of  the  types  that  require  a 
constraint.  However,  the  generic  bodies  are  compiled  after  the  units 
that  contain  the  instantiations,  and  this  implementation  creates  a 
dependence  of  the  instantiating  units  on  the  generic  units  as  allowed 
by  AI-00408  and  AI-00506  such  that  the  compilation  of  the  generic 
bodies  makes  the  instantiating  units  obsolete — no  errors  are  detected. 
The  processing  of  these  tests  was  modified  by  re-compiling  the 
obsolete  units;  all  intended  errors  were  then  detected  by  the 
compiler. 

BC3204D  and  BC3205C  were  graded  passed  by  Test  Modification  as  directed 
by  the  AVO.  These  tests  are  similar  to  BC3204C  and  BC3205D  above, 
except  that  all  compilation  units  are  contained  in  a  single 
compilation.  For  these  two  tests,  a  copy  of  the  main  procedure  (which 
later  units  make  obsolete)  was  appended  to  the  tests;  all  expected 
errors  were  then  detected. 

CD2A53A  was  graded  inapplicable  by  Evaluation  Modification  as  directed 
by  the  AVO.  The  teat  contains  a  specification  of  a  power-of-10  value 
as  'SMALL  for  a  fixed-point  type.  The  AVO  ruled  that,  under  ACVC 
1.11,  support  of  decimal  'SMALLs  may  be  omitted. 

AD9001B  and  AD9004A  were  graded  passed  by  Processing  Modification  as 
directed  by  the  AVO.  These  tests  check  that  various  subprograms  may  be 
interfaced  to  external  routines  (and  hence  have  no  Ada  bodies).  This 
implementation  requires  that  a  file  specification  exists  for  the 
foreign  subprogram  bodies.  The  following  command  was  issued  to  the 
Librarian  to  inform  it  that  the  foreign  bodies  will  be  supplied  at  link 
time  (as  the  bodies  are  not  actually  needed  by  the  program,  this 
command  alone  is  sufficient): 

zalib  interface/system/library«lib_name  ad9001b  &  ad9004a 
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PROCESSING  INFORMATION 


3 . 1  TESTING  ENVIRONMENT 

The  Ada  implementation  tested  in  this  validation  effort  is  described 
adequately  by  the  information  given  in  the  initial  pages  of  this  report. 

For  technical  and  sales  information  about  this  Ada  implementation,  contact: 


Proprietary  Software  Systems,  Inc.  (PSS) 
Mr.  Richard  Gilinski 
429  Santa  Monica  Blvd. 

Santa  Monica,  California  90401 
USA 

Tel.  (301)  394-S233 
Fax  (301)  393-3122 


Testing  of  this  Ada  implementation  was  conducted  at  the  AVF's  site  by  a 
validation  team  from  the  AVF. 


3.2  SUMMARY  OF  TEST  REStJLTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test 
of  the  customized  test  suite  in  accordance  with  the  Ada  Programming  Language 
Standard,  whether  the  test  is  applicable  or  inapplicable;  otherwise,  the  Ada 
Implementation  fails  the  ACVC  (Pro90]. 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was  obtained 
that  conforms  to  the  Ada  Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various  categories. 
All  tests  were  processed,  except  those  that  were  withdrawn  because  of  test 
errors  (item  b;  see  section  2.1),  those  that  require  a  floating-point 
precision  that  exceeds  the  implementation's  m£ucimum  precision  (item  e;  see 
section  2.2),  and  those  that  depend  on  the  support  of  a  file  system  —  if 
none  is  supported  (item  d).  All  tests  passed,  except  those  that  are  listed 
in  sections  2.1  and  2.2  (counted  in  items  b  and  f,  below). 
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a)  Total  Number  of  Applic2ible  Tests  3388 

b)  Total  Number  of  Withdrawn  Tests  95 

c)  Processed  Inapplicable  Tests  96 

d)  Non-Processed  I/O  Tests  264 

e)  Non-Processed  Floating-Point 

Precision  Tests  327 


f)  Total  Number  of  Inapplicable  Tests  687  (c+d-i-e) 

g)  Total  Number  of  Teats  for  ACVC  1.11  4170  (a+b+f) 


3 . 3  TEST  EXECUTION 

With  the  customer ' s  macro  parameters  a  customised  test  suite  was  produced  on 
the  host  computer  system  (VAX  8350)  which  was  used  for  running  the 
validation.  Next  the  Ada  implementation,  the  bare  target  simulation  program 
and  the  command  scripts,  as  supplied  by  the  customer,  were  loaded  and 
installed  on  the  host.  Then  the  full  set  of  customised  tests  was  processed 
by  the  Ada  implementation. 

The  tests  were  compiled  and  linked  on  the  host  computer  system,  as 
appropriate.  The  executable  images  were  executed  by  the  bare  target 
simulation  program  on  the  host  computer  system.  The  results  were  captured  on 
the  host  computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the  customer  and 
reviewed  by  the  validation  team.  See  Appendix  B  for  a  complete  listing  of 
the  processing  options  for  this  implementation.  It  also  indicates  the 
default  options.  The  options  invoked  explicitly  for  validation  testing 
during  this  test  were  for  compiling 

class-B-  and  class-E-tests 

REPLACE 
LIST*SOURCE 

NOSAVE_SOURCE 
LIBRARYsiiJbrary  name 
WIDTH=79 

all  other  test  classes 

REPLACE  replace  exisiting  unit  in  library 

NOSAVE_SOURCE  don't  keep  the  source  listing  in  the  library 

LIBRARY=Iibrary_naoie  name  of  the  library  where  the  unit  is  compiled 

No  explicit  linker  options  were  used  except  for  tests  AD9001B  and  AD9004A 
( see  2.3). 

Test  output,  compiler  and  linker  listings,  and  job  logs  were  captured  on  a 
magnetic  tape  and  archived  at  the  AVF.  The  listings  examined  by  the 
validation  team  were  also  archived. 


replace  exisitrng  unit  rn  library 
produce  a  compilation  listing  with  embedded 
error  messages 

don't  keep  the  source  listing  in  the  library 
name  of  the  library  where  the  unit  is  compiled 
width  of  compilation  listing 
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MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC. 
The  meaning  and  purpose  of  these  pariuneters  are  explained  in  [UG89].  The 
parameter  values  are  presented  in  two  tcUales.  The  first  table  lists  the 
values  that  are  defined  in  terms  of  the  maximum  input-line  length,  which  is 
the  value  for  $MAX_IN_LEN — also  listed  here.  These  values  are  expressed  here 
as  Ada  string  aggregates,  where  ”V”  represents  the  maximum  input-line 
length. 


Macro  Parameter  Macro  Value 


$MAX_IN_I.EN  240  —  Value  of  V 

$BIG_ID1  (1..V-1  «>  'A',  V  ->  '1') 

$BIG_ID2  (1..V-1  »>  'A',  V  »>  '2') 

$BIG  ID3  (1..V/2  »>  'A')  &  '3'  & 

(1..V-1-V/2  «>  'A') 

SBIG  ID4  (l*-V/2  »>  'A')  &  '4'  & 

(1..V-1-V/2  ->  'A') 

SBIG_INT_I.IT  (1..V-3  »>  '0')  &  "298" 

$BIG_REAL_LIT  {1..V-5  ->  '0')  &  "690.0" 

$BIG_STRING1  £  (1..V/2  »>  'A')  £ 

SBIG_STRING2  £  (1..V-1-V/2  ->  'A')  £  '1'  £ 

SBLANKS  (1..V-20  «>  '  ' ) 

SMAX_LEN  INT_BASED  LITERAL 

"2:"  £  {1..V-5  »>  '0')  £  "11;" 

SMAX  LEN_REAL  BASED  LITERAL 

“  “  "16:"  £  (1..V-7  «>  '0')  £  "F.E:" 

SMAX_STRING_LITERAL  £  (1..V-2  »>  'A')  £ 


The  following  table  lists  all  of  the  other  macro  parameters  and  their 
respective  values. 
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Macro  Pareuneter  Macro  Value 


$ACC_SIZE 

$ALIGNMENT 

SCOUNT_LAST 

$DEFAULT_MEM_S I ZE 

$DEFAULT_STOR_UNIT 

$DEFAULT_SYS_NAME 

$DELTA_DOC 

$ENTRY_AOOR£SS 

SENTRY_ADDRESS1 

$ENTRY_ADDRESS2 

$FIELD_LAST 

$ F I LE_TERM I N ATOR 

SFIXED_NAME 

$FLOAT_NAME 

SFORM_STRING 

$FORM_STRING2 

$GREATER  THAN  DURATION 


24 

8 

252 

131072 

24 

ZR34325 

2#1.0#E-23 

0 

1 

2 

252 

ASCI I. EOF 

NO__SOCH_FIXED_TYPE 

NO_SUCH_FI.OAT_TYPE 

«  M 

CANNOT  RESTRICT  FILE  CPACITY 


90_000.0 

$GREATER  THAN_DURATION  BASE  LAST 

T31_073.0 

$GREATER  THAN  FLOAT  BASE_LAST 

1.80141E-t-38 

$GREATER  THAN_FLOAT  SAFE  LARGE 

1.0E308 

$GREATER_THAN_SHORT_FLOAT_SAFE_LARGE 

1.0E308 

SHIGH_PRIORITY  200 

$ILLEGAL_EXTERNAL  FILE_NAME1 

BAO&BAO 

$ ILLEGAL  EXTERNAL  FILE_NAME2 

~  ~  BAO&BAO&BAO 

$ INAPPROPRIATE  LINE  LENGTH 

”  -1 


$ INAPPROPRIATE  PAGE  LENGTH 

~  -1 

$INCLUDE_PRAGMA1  PRAGMA  INCLUDE  ( ''A28006D1 .  ADA"  ) 
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$ INCLUDE_PRAGMA2 
$INTEGER_FIRST 
$ INTEGER  LAST 


PRAGMA  INCLUDE  ( "B28006F1 . ADA" ) 

-8388608 

8388607 


$INTEGER_LAST_PLUS_1  8388608 

$INTERFACE_LANGUAGE  CLINK 

$LESS_THAN_DURATION  -90_000 -  0 

SLESS  THAN_DURATION  BASE  FIRST 

-111  073.0 


SLINE_TERMINATOR 
$LOW  PRIORITY 


ASCIl.CR 

10 


$MACHINE_CODE  STATEMENT 

2' (TRAN, (GEN, 3,0,0)); 


$MACHINE_CODE_TYPE 

$MANTISSA_DOC 

$MAX_DIGITS 

$MAX_INT 

$MAX_INT_PLUS_1 

SMIN_INT 

$NAME 

$NAME_LIST 

$NEG_BASED_INT 

$NEW_MEM_SIZE 

$NEW_STOR_UNIT 

$NEW_SYS_NAME 

$ P AGE_TERM I NATOR 

$RECORO  DEFINITION 


$RECORD_NAME 
$TASK_SIZE 
$TASK_STORAGE_S I ZE 
STICK 

$VARIABLE_ADDRESS 
$ VARI ABLE_ADDR£SS 1 
SVARIABLE  AODRESS2 


OP_CODE 

23 
6 

8388607 

8_338_608 

-8388608 

NO_OTHER_INTEGER_TYPE 

ZR3432S 

16#FFFFFE# 

131072 

24 

ZR34325 
ASCII. FF 
RECORD 

OPERATION ; OP_CODE ; 
OPERANDS:  OPERAND; 

END  RECORD; 

Z 

24 

2048 

0.02 

0 

1 

2 
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COMPILATION  AND  LINKER  SYSTEM  OPTIONS 


The  compiler  and  linker  options  of  this  Ada  implementation,  as 
described  in  this  Appendix,  are  provided  by  the  customer.  Unless 
specifically  noted  otherwise,  references  in  this  appendix  are  to 
compiler  documentation  and  not  to  this  report. 
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4.4.  ADA  Command  Line  Qualifiers 

4.4.1.  /[NO]CROSS_REFERENCE 

Specifying  /CROSS_REFERENCE  results  in  a  cross  reference  listing  being  generated  as 
part  of  the  .MLS  listing  file. 

The  default  is  /NOCROSS_REFERENCE 


4.4.2.  /[NOJDEBUG 

Specifying  /DEBUG  results  in  the  inclusion  of  symbolic  debug  information  in  the  object 
file.  This  information  will  be  included  at  link  time  in  the  executable  image  file  so  that 
symbolic  debugging  may  be  performed.  /NODEBUG  results  in  no  debug  information  in 
the  object  file. 

The  default  is  /NODEBUG. 


4.4.3.  /[NOJJUMP^PADDING 

When  an  interrupt  or  a  fault  needs  to  result  in  the  raising  of  an  exception,  the  flow  of 
control  is  changed  in  the  interrupt  handler  so  that  control  is  passed  to  the  exception 
raising  program,  instead  of  returning  to  the  point  of  the  interrupt  or  fault.  However,  if 
there  is  a  control  branch  instruction  waiting  in  the  FIFO  when  the  interrupt  or  fault  occurs, 
then  control  may  never  reach  the  exception  raising  program.  To  avoid  this  problem,  the 
compiler  generates  an  extra  conditional  jump  in  front  of  every  branch  instruction  (JMP, 
JMPC,  CALL,  RET).  If  this  is  not  an  issue  for  the  system  under  development  (for 
example,  all  interrupts  are  to  be  masked,  or  all  interrupts  will  have  control  returned  to  the 
point  of  the  interrupt),  then  these  extra  jumps  may  be  omitted  by  using 
/NOJUMP_PADDING. 

The  default  in  /JUMP_PADDING. 


4.4.4.  /UBRARY- library-name 

Specifies  the  library  into  which  the  file  is  to  be  compiled. 
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4.4.5.  /LENGTH =nn 

The  /LENGTH  option  allows  you  to  specify  the  number  of  lines  per  page  that  are 
produced  in  the  .US  file.  The  default  value  is  60. 


4.4.6.  /[NO]LIST[ = listing-option-list] 

listing-option-list:  Specifies  the  type  of  listing(s)  to  be  generated.  Allowable  options  are: 
SOURCE 
MACHINECODE 
EMBEDDED_SOURCE 
ALL 

The  default  is  /NOUST.  Any  combination  of  SOURCE,  MACH1NE_C0DE  and 
EMBEDDED_SOURCE  may  be  specified;  however,  EMBEDDED_SOURCE  only  takes 
effect  when  MACHINE_CODE  is  also  specified.  To  specify  multiple  suboptions,  enclose 
in  parentheses  and  separate  suboptions  with  commas.  Example: 

/LIST=  (SOURCE, MACHINE_CODE) 

/UST= SOURCE  produces  a  listing  of  the  source  text  with  line  numbers  prefixed  to  each 
source  line.  The  list  file  produced  has  the  same  name  as  the  source  file  but  with  a  file 
type  of  .US. 

/UST= MACHINE  produces  a  listing  file  of  the  machine  code  generated  by  the  Ada 
Compiler  including  both  the  generated  assembly  code  and  the  hexadecimal 
representation.  The  listing  file  that  is  produced  has  the  same  name  as  the  source  file  but 
with  a  file  type  .MLS. 

/UST =ALL  is  the  same  as: 

/LIST  =  (SOURCE, MACHINE_CODE,EMBEDDED_SOURCE) 

/UST  is  the  same  as: 

/UST = SOURCE 


4.4.7.  /NOENUMIMAGE 

When  an  enumeration  type  is  declared,  constants  are  allocated  for  the  ’IMAGE  attribute 
of  the  type-that  is,  character  constants  containing  the  names  of  the  elements  of  the 
enumeration  constants  are  created.  If  the  user  does  not  intend  to  use  ’IMAGE  or  ’VALUE 
for  these  enumeration  types,  then  these  constants  can  be  omitted  by  using 
/NOENUMIMAGE. 
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There  is  no  /ENUMIMAGE  option;  the  default  is  that  the  character  constants  are 
allocated. 


4.4.8.  /[NO]OPTIMIZE 

/OPTIMIZE  causes  the  Ada  Compiler  to  produce  optimized  code.  This  takes  the  place 
of  the  pragma  for  optimization.  The  Ada  Compiler  produces  code  that  has  been 
optimized  for  both  time  and  space.  The  default  is  /OPTIMIZE. 


4.4.9.  /[NO]PHASES 

This  option  controls  whether  the  compiler  announces  each  phase  of  processing  as  it 
occurs.  These  phases  indicate  progress  of  the  compilation.  The  default  is  /NOPHASE. 


4.4.10.  /[NOJPROTECT  RAM 

It  is  assumed  that  the  user  will  be  making  use  of  the  Zoran  RAM  via  MSPs  or  assembly 
code.  In  the  instances  where  the  compiler  must  use  the  RAM  (e.g.,  multiplication, 
integer-to-float  and  float-to-integer  conversions),  if  /PROTECT_RAM  is  selected,  the 
entries  of  the  RAM  that  are  used  by  the  compiler  will  be  saved  and  restored  so  as  not  to 
interfere  with  values  that  the  user  has  loaded.  If  the  values  in  the  RAM  are  expendable, 
the  save/restore  of  these  values  may  be  omitted  by  using  /NOPROTECT_RAM. 

The  default  is  /PROTECT_RAM. 


4.4.11.  /INO]REFINE 

Controls  whether  the  compiler,  when  compiling  a  library  unit,  determines  whether  the  unit 
is  a  refinement  of  its  previous  version  and,  if  so,  does  not  make  dependent  units  obsolete. 
The  default  is  /NOREFINE. 


4.4.12.  /[NO]SAVE_SOURCE 

Controls  the  creation  of  a  safety  copy  of  the  source  code  in  the  library  directory.  The 
default  is  /SAVE_SOURCE.  You  may  save  disk  space  by  using  /NOSAVE_SOURCE. 
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4.4.13.  /[NO]SHORTJNT_COMPARE 

Selecting  /SHORTJNT_COMPARE  results  in  simpler  code  for  integer  compares.  Only 
a  subtract  is  performed  to  set  the  condition  codes.  However,  if  numbers  being  compared 
have  values  such  that  a  subtraction  causes  an  overflow  (such  as  (2**23)-l  and  -1),  then 
incorrect  results  will  be  obtained.  If  such  comparisons  may  occur,  use 
/NOSHORTJNT  COMPARE.  If  it  may  be  guaranteed  that  such  comparisons  will  not 
occur,  then  use  7SHORTJNT_COMPARE  to  obtain  more  efficient  code. 

The  default  is  /NOSHORTJNT_COMPARE. 


4.4.14.  /[UO]S\JPPRBSS[= suppress-option] 

suppress-option;  Specifies  the  various  Ada  checks  that  are  to  be  suppressed.  Multiple 
suppress-options  can  be  supplied  by  separating  them  with  commas  and  enclosing  the  list 
in  parentheses. 

/SUPPRESS =CONSTRAINT_CHECKS  causes  the  Ada  Compiler  to  eliminate  all  checks 
performed  to  test  for  constraint  errors.  This  compiler  option  is  used  where  higher 
execution  performance  is  necessary. 

/SUPPRESS = ELAB0RAT10N_CHECKS  causes  the  Ada  Compiler  to  eliminate  all  checks 
performed  during  elaboration.  This  compiler  option  is  used  where  elaboration  order  is 
specified  by  the  user  or  higher  execution  performance  is  necessary. 

/SUPPRESS =STACK_CHECKS  causes  the  Ada  Compiler  to  eliminate  all  checks  on  the 
run-time  stack.  This  compiler  option  is  used  where  higher  execution  performance  is 
necessary. 

/SUPPRESS = ALL  has  the  same  effect  as  combining  every  suppress  option. 


4.4.15.  /SYNTAX  ONLY 

Parses  a  unit  and  reports  syntax  errors,  then  stops  compilation  without  entering  a  unit  in 
the  library. 


4.4.16.  /WIDTH =nn 

The  /WIDTH  option  allows  you  to  specify  the  width  of  the  .LIS  listing  file  that  is  produced. 
The  default  value  is  124  characters. 
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VISIBLE  only  visible  imports  can  overwrite  a  local  unit. 

HIDDEN  both  visible  and  hidden  imports  can  overwrite  local  units. 

NONE  no  imported  units  (visible  or  hidden)  may  overwrite  local  units. 

/[NOJCONFIRM:  Requests  that  the  user  be  given  the  opportunity  to  confirm  before  each 
compilation  unit  is  imported.  NOCONFIRM  is  the  default. 

/[NO] LOG:  Causes  a  message  to  be  written  to  the  standard  output  device  when  a 
compilation  unit  is  imported.  NOLOG  is  the  default. 


3.3.16.  LINK //qua//7/er...7  comp-unit-name 

This  command  performs  the  following  actions: 

checks  that  the  unit  within  the  library  specified  by  the  user  has  the  legal  form  for 
a  main  unit 

checks  the  consistency  of  the  unit’s  link  closure 
finds  all  required  object  files 

links  the  main  program  with  its  link  closure  producing  an  executable  image  in  the 
default  directory. 

comp-unit-name:  Specifies  the  unit  to  be  made  the  main  program.  An  error  message  is 
issued  If  the  compilation  unit  does  not  exist.  All  units  in  the  link  closure  must  exist  and 
must  be  consistent. 

The  following  command  qualifiers  may  be  used: 

/[NO] KEEP:  controls  whether  temporary  files  created  by  the  librarian  are  deleted. 
/NOKEEP  is  the  default. 

/UBRARY = library-name:  Specifies  the  project  and  name  of  the  library  containing  the 
compilation  unit  to  be  made  a  main  program.  An  error  message  is  issued  if  the  library  is 
a  specification  library.  An  error  message  is  issued  if  the  project  does  not  exist.  The 
project  need  not  be  specified  If  there  is  a  default  project.  An  error  message  is  issued  if 
it  is  not  specified  and  there  is  no  default  project.  An  error  message  is  issued  if  the  library 
does  not  exist.  The  library  need  not  be  specified  if  there  is  a  default  library.  An  error 
message  is  issued  if  a  library  is  not  specified  and  there  is  not  a  default  library. 
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APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  implementation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine-dependent 
conventions  as  mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to 
certain  allowed  restrictions  on  representation  clauses.  The 
implementation-dependent  characteristics  of  this  Ada  implementation, 
as  described  in  this  Appendix,  are  provided  by  the  customer.  Unless 
specifically  noted  otherwise,  references  in  this  Appendix  are  to 
compiler  documentation  and  not  to  this  report.  Implementation-specific 
portions  of  the  package  STANDARD  can  be  found  on  page  12  of  the 
following  documentation. 
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MIL-STD-1815A  Appendix  F 

This  section  discusses  the  MIL-STD-1815A  Appendix  F  issues 
that  are  left  up  to  the  implementor. 

Predefined  Pragmas 

The  LACE  Ada  Compiler  supports  the  following  predefined 
pragmas : 

ELABORATE,  INLINE,  LIST,  PACK,  PAGE,  PRIORITY,  and  SUPPRESS 

Pragmas  LIST  and  PAGE  have  effect  only  if  there  are  no 
compilation  errors  or  warnings  in  the  units  which  contain 
them. 

Pragma  PACK  causes  the  densest  possible  representation  to  be 
used.  If  a  length  cla-  se  is  a^^^-xed  to  the  array  type,  then 
the  pragma  is  ignored.  If  a  length  clause  is  applied  to  the 
component  type  of  a:,  array,  then  the  array  is  packed  as 
tightly  as  possible,  using  the  specified  size  of  the 
component.  Notn  that  pragma  PACK  does  not  change  the 
allocation  of  string  types  or  other  arrays  of  characters. 
Characters  are  allocated  one  per  referable  unit.  For  records, 
the  compiler  chooses  the  densest  possible  allocation  that 
conforms  to  all  size  and  alignment  constraints  for  all 
components  of  the  record.  Pragma  PACK  has  an  effect  only  if 
some  of  the  component  types  have  size  specifications  and  are 
non-ref erable.  Otherwise,  each  component  is  allocated  a 
referable  amount  of  space.  Note  hat  boolean  types,  and  other 
types  that  require  exactly  one  bit,  are  packed  in  records  only 
if  there  is  more  than  one  such  component  within  the  record. 
Otherwise,  a  single,  one-bit  item  will  occupy  a  referable 
unit.  Pragma  PACK  does  not  change  the  allocation  of  any 
component  placed  by  a  component  clause.  Also,  pragma  PACK 
does  not  make  use  of  gaps  left  within  the  record  as  a  result 
of  such  specifications.  See  the  descriptions  of  size 
specifications  for  arrays  and  size  specifications  for  records, 
later  in  this  section,  for  additional  information  about  array 
and  record  allocation. 

The  compiler  accepts  pragmas  MEMORy_SIZE,  STORAGE^UNIT  and 
SYSTEM_NAME,  but  only  the  predefined  values  defined  in  package 
SYSTEM  are  allowed. 

The  compiler  accepts  pragma  INTERFACE,  but  only  CLINK  is 
allowed  as  the  language  name.  The  linkage  conventions  used 
for  CLINK  are  the  same  as  the  standard  Ada  linkage 
conventions.  The  compiler  may  rename  entities  that  have 
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pragma  INTERFACE  applied  to  them,  thereby  requiring  the  user 
to  examine  the  generated  name  in  order  to  provide  an 
implementation  routine  with  the  same  spelling.  The 
implementation-defined  pragma  LINKAGE_NAME  (see  below)  may  be 
used  to  force  the  compiler  to  use  a  specific  name  for  an 
entity.  Furthermore,  implementation-defined  pragma 

FOREIGN_BODY,  in  conjunction  with  pragma  LINKAGE_NAME ,  may  be 
used  to  achieve  an  effect  similar  to  that  of  INTERFACE. 

The  LACE  Ada  Compiler  does  not  support  the  following 
predefined  pragmas: 

CONTROLLED:  This  is  not  supported  because  automatic  storage 
reclamation  does  not  occur. 

OPTIMIZE:  Optimization  is  controlled  via  command  line 

option. 

SHARED:  This  pragma  is  not  supported.  No  warning  is 

generated  if  SHARED  is  used. 

Implementation-defined  Pragmas 

The  LACE  Ada  Compiler  also  supports  the  following 
implementation-defined  pragmas: 

Pragma  LINKAGE_NAME 

Pragma  LINKAGE_NAME  is  used  to  specify  an  exact  external  name 
to  a  given  linkable  entity  (such  as  a  function  or  a  variable) . 
The  syntax  is: 

pragma  LINKAGE_NAME  (  Ada-simple-name,  string-constant)  ; 

Ada-simple-name  must  be  the  name  of  an  Ada  entity  declared  in 
a  package  specification,  or  the  name  of  a  library-level 
subprogram  or  function.  This  entity  must  be  something  that 
exists  at  runtime,  such  as  a  subprogram,  an  exception,  or  an 
object.  It  cannot  be  a  named  number  or  string  constant.  The 
pragma  is  placed  after  the  declaration  of  the  entity. 

LINKAGE_NAME  causes  the  string-constant  to  be  used  in  the 
generated  object  code  for  references  to  the  Ada-simple-name. 
The  user  must  assure  that  the  name  specified  by 
string-constant  is  unique  for  the  program  under  construction, 
and  that  the  form  of  the  name  is  legal. 

An  example  of  pragma  LINKAGE_NAME  usage: 

procedure  SPECIAL_CASE  (  x,  y  :  integer)  ; 

pragma  LINKAGE_NAME  (SPECIAL_CASE,  "xx_Special_Case" )  ; 
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Here,  the  procedure  SPECIAL_CASE  is  provided  with  the  linkage 
name  xx_Special_Case.  As  a  result,  all  calls  to  SPECIAL_CASE 
will  result  in  a  reference  in  the  object  code  to  the  external 
name  xx_Special_Case. 

Pragma  FOREIGN_BODY 

Pragma  FOREIGN_BODY  provides  a  method  to  access  subprograms 
and  data  written  in  other  languages — or  even  other  Ada 
programs.  Pragma  FOREIGN_BODY  expands  upon  the  utility  of 
pragma  INTERFACE  by  providing  the  capability  of  accessing  data 
as  well  as  subprograms  written  in  other  languages.  The  syntax 
is: 


pragma  FOItEIGN_BOOY  ( I anguage_name  t.elaboration_routine_naffle] )  ; 


Pragma  FOREIGN_BODY  must  appear  in  a  non-generic  library 
package.  It  must  appear  before  any  declarations.  A  package 
that  includes  pragma  FOREIGN_BODY  may  not  include  any  type 
declarations.  All  objects,  subprograms,  functions,  and 
exceptions  declared  in  such  a  package  must  be  supplied  by  a 
foreign  object  module. 

Language_name  is  a  string.  Any  string  may  be  used;  the  LACE 
compiler  will  follow  its  standard  linkage  conventions  for  all 
subprogram  and  function  calls.  The  user  must  assure  that 
these  conventions  are  adhered  to  in  the  actual  foreign  object 
module. 

The  optional  elaboration_routine_name  is  a  string  which,  if 
supplied,  results  in  a  call  to  a  procedure  of  that  name  during 
program  elaboration.  This  elaboration  routine  must  be 
provided  in  the  foreign  object  module  supplied  by  the  user. 
The  user  is  responsible  for  initialization  of  all  objects 
within  such  a  package,  whether  or  not  an  elaboration  routine 
is  specified. 

A  package  that  uses  pragma  FOREIGN_BODY  may  contain  only 
subprogram  declarations,  object  declarations  that  use 
unconstrained  type  marks,  number  declarations,  and  other 
pragmas.  No  object  whose  type  mark  is  a  task  type,  or 
includes  a  component  whose  type  mark  is  a  task  type,  may  be 
included  in  such  a  package.  If  any  of  the  restrictions  for 
pragma  FOREIGN_BODY  are  violated,  then  the  pragma  is  ignored, 
and  a  warning  message  is  issued. 

Pragma  LINKAGE_NAME  should  be  used  for  all  declarations  in  a 
package  that  uses  pramga  FOREIGN_BODY .  When  LINKAGE_NAME  is 
not  used  for  a  given  entity,  the  compiler  may  rename  that 


3 


entity,  and  use  this  new  spelling  for  all  references  to  the 
entity.  Thus,  when  the  foreign  object  module  is  supplied,  the 
references  from  other  Ada  units  will  not  resolve  at  link  time. 

The  user  specifies  the  foreign  object  module  to  the  librarian 
via  the  FOREIGN_BODY  command.  For  example,  for  a  package 
named  STUFF  that  includes  pragma  FOREIGN_BODY ,  one  would 
issue  the  following  librarian  command  to  provide  a  foreign 
object  module  named  STUFF_BODY . OB J  for  package  STUFF: 

ZALIB/LlBRARYsproject: library  FOREIGM_BOOY  STUFF  STUFF_BOOY.OBJ 

See  the  section  on  the  librarian  commands  for  more  information 
on  the  FOREIGN_BODY  command. 

An  example  of  pragma  FOREIGN_BODY  usage: 


package  STUFF  is 

pragma  FOREIGN_BOOY( “assembly",  “xx_stuff_elab"); 
xyz  ;  integer; 

pragma  LINICAGE_NAME  (xyz,  "xx_xyz“); 

procedure  SPECIAL_CASE  (  x,  y  :  integer)  ; 

pragma  HNKAGE_NAME  (SPECIAL_CASE.  “xx_Special_Case")  ; 

end  STUFF; 

Compilation  of  Package  STUFF  will  generate  no  object  code. 
Instead,  the  user  must  supply  an  object  module  for  STUFF  via 
the  FOREIGN_BODY  command  to  the  librarian,  as  described  above. 
In  the  object  module  for  STUFF  there  should  be  at  least  three 
externally  referable  labels:  xx_stuf f_elab,  xx_xy2,  and 

xx_Special_Case.  Xx_stuff_elab  should  be  the  entry  point  of 
a  parameter less  procedure;  this  procedure  will  be  called  to 
perform  the  elaboration  for  package  STUFF.  Xx_xyz  should  be 
a  label  for  an  integer  data  object;  references  to  STUFF. XYZ 
will  resolve  to  references  to  xx_xyz.  Xx_Special_Case  should 
be  the  entry  point  for  the  implementation  of  procedure 
SPECIAL_CASE ;  calls  to  SPECIAL_CASE  will  result  in  calls  to 
xx_Special_Case . 

Implementation-dependent  Attributes 

The  LACE  Ada  Compiler  supports  no  implementation-dependent 
attributes . 

Package  SYSTEM 

The  predefined  package  SYSTEM  contains  the  definitions  of 
certain  implementation  defined  characteristics.  SYSTEM  is 
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defined  for  the  LACE  Ada  Compiler  as  follows: 


package  system  is 

--  Package  System  for  PSS  Ada  Zoran  Target 
subtype  address  is  neu  integer; 
type  name  is  (ZR34325}; 
system_name  :  constant  name  ZR3432S; 

storage_init  :  constant  :■  24  ;  --  24  bits  per  storage  unit 

swfflory_size  :  constant  131072;  --  128K  units 

max_int  :  constant  :«  8388607;  --  24  bit  integer 

min_int  :  constant  :■  -max_int  -  1; 

max^digits  :  constant  6;  --  6  digits  for  floating  point 

max_mantissa  :  constant  23;  **  fraction  for  fixed  point 

fine_delta  :  constant  :»  2#1.0#e-23;  --  for  fixed  point 

tick  :  constant  0.02;  -■  delta  of  tick 

subtype  priority  is  integer  range  10  ..  200; 
default_priority  ;  constant  priority  :»  priority'f irst; 
runtime_error  :  exception; 
end  system; 

Restrictions  on  Representation  Clauses 

The  LACE  compiler  has  a  basic  restriction  on  all 
representation  clauses: 

o  Representation  clauses  may  be  given  only  for  types 
declared  in  terms  of  a  type  definition,  excluding 
gener ic_type_def init ions  ( LRM  12.1)  and 
private_type_de'f initions  (LRM  7.4). 

Furthermore,  some  types  have  minimal  alignment  requirements 
that  must  be  adhered  to  when  specifying  representations.  Any 
representation  that  does  not  meet  these  requirements  is 
diagnosed  by  the  compiler  and  ignored.  The  general  rule  for 
minimal  alignment  of  types  is  summarized: 

o  No  object  of  scalar  type,  including  components  of  a 
composite  type,  may  span  a  target-def ined  address 
boundary  that  would  mandate  an  extraction  of  the  object's 
value  to  be  performed  by  two  or  more  extractions. 

Any  representation  clause  in  violation  of  the  above  rules  is 
diagnosed,  and  is  not  obeyed.  The  following  sections  describe 
further  restrictions.  A  violation  of  any  of  these 
restrictions  results  in  a  diagnostic  message  from  the 
compiler. 

Restrictions  on  Size  Specifications 

The  following  fundamental  rules  apply  to  all  classes  of  size 
specifications : 

o  The  size  is  specified  in  bits  and  must  be  given  by  a 
static  expression. 
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o  The  given  size  is  taken  as  a  request  to  store  objects  of 
the  type  in  that  number  of  bits  when  feasible — use  of  a 
smaller  size  is  never  attempted,  even  if  possible.  The 
following  describe  what  is  feasible: 

o  An  object  that  is  not  a  component  of  a  composite 
object  is  allocated  with  a  size  and  alignment  that 
is  referable  on  the  target  machine.  In  other 
words,  multiple  individual  objects  are  never  packed 
into  a  single  address  unit.  If  such  packing  is 
desired,  combine  the  individual  objects  into  a 
component  structure,  and  specify  the  components. 

o  Formal  parameters  of  a  type  with  a  specified  size 
are  allocated  as  is  required  by  parameter  passing 
conventions.  Any  necessary  size  conversions  are 
performed  during  parameter  passing  and  are 
transparent  to  the  user. 

o  For  a  component  within  a  composite  type,  if  adjacent 
bits  are  not  otherwise  occupied,  they  may  be 
affected  by  stores  to  the  component;  the  compiler 
will  allocate  unused  bits  to  non-referable 
components  to  make  them  referable. 

o  A  size  specification  for  a  type  specifies  the  size  for 
objects  of  that  type  and  for  any  subtypes  of  the  type. 
Even  if  a  subtype  would  allow  for  a  smaller 
representation,  no  attempt  is  made  to  use  the  smaller 
size. 

o  A  size  specification  for  an  access  type  must  match  the 
default  size  used  by  the  compiler  for  the  type. 

o  Size  specifications  are  not  supported  for  floating  point 
types  or  task  types. 

The  following  sections  describe  restrictions  that  are  unique 
to  each  class  of  size  specification. 


6 


Restrictions  on  Size  Specifications  for  Scalar  Types 

Any  size  must  be  large  enough  to  accommodate  all  possible 
values  of  the  type  including  the  value  0,  even  if  0  is  not  in 
the  range  of  the  values  of  the  type.  For  numeric  types  with 
negative  values,  the  size  must  include  the  sign  bit. 

A  size  specification  for  a  real  type  does  not  affect  the 
accuracy  of  operations  for  that  type. 

A  size  specification  may  not  specify  a  size  larger  than  the 
largest  size  supported  by  the  target  architecture  for  the 
representation  of  objects  of  that  class  of  type.  For  the  LACE 
compiler,  the  largest  sizes  are: 

enumeration:  24  bits 
integer:  24  bits 
fixed:  24  bits 
float:  24  bits 

Restrictions  on  Size  Specifications  for  Array  Types 

A  size  specification  for  an  array  type  must  be  large  enough 
to  accommodate  all  components  of  the  array  under  the  densest 
packing  strategy.  Alignment  constraints  on  all  components 
must  be  obeyed — such  constraints  are  described  in  a  later 
section. 

Arrays  with  component  sizes  less  than  or  equal  to  24  bits  are 
densely  packed;  no  pad  or  unused  bits  exist  between 
components.  Arrays  with  component  sizes  greater  than  24  bits 
are  padded  up  to  the  next  24-bit  (i.e.,  referable  unit) 
boundary.  The  size  of  the  component  type  is  not  influenced 
by  the  size  clause  for  the  array.  However,  the  representation 
of  components  declared  via  a  subtype  may  be  reduced  to  the 
minimum  number  of  bits  required  for  the  range  of  values  of  the 
subtype  (but  not  of  the  parent  type) ,  unless  the  parent  type 
has  a  size  specification. 

If  there  is  a  size  specification  for  the  component  type,  but 
not  for  the  array  type,  then  the  component  size  is  rounded  up 
to  the  nearest  referable  size,  unless  pragma  PACK  is  used. 
This  even  applies  to  boolean  types  or  other  types  that  require 
only  a  single  bit. 

Restrictions  on  Size  Specifications  for  Record  Types 

A  size  specification  for  a  record  type  does  not  change  the 
default  layout  of  the  record  type.  Any  size  given  for  a 
record  type  must  be  at  least  as  large  as  the  number  of  bits 
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determined  by  the  default  layout.  Changing  of  the  layout  of 
a  record  type  must  be  done  by  use  of  record  representation 
clauses  or  by  pragma  PACK.  As  a  consequence,  size 

specifications  for  record  types  can  only  be  used  to  increase 
the  size  of  the  record.  Any  decrease  in  the  size  of  a  record 
type  must  be  achieved  by  using  pragma  PACK  or  by  using 
representation  clauses. 

Neither  the  size  nor  representation  of  component  types  of  a 
record  are  altered  by  a  length  clause  for  a  record. 

If  a  record  contains  an  array  component  whose  bounds  depend 
on  discriminants  of  the  record  or  contains  components  of 
dynamic  size,  then  implementation-  dependent  dope  information 
components  are  allocated  within  the  record.  These  dope 
components  cannot  be  named  or  sized  by  the  user. 

A  size  specification  may  not  be  applied  to  a  record  type  with 
dynamically  sized  components. 

Restrictions  on  Size  Specifications  for  Collections 

The  specification  of  a  collection  size  causes  the  collection 
to  be  allocated  with  at  least  the  specified  size.  The  size 
is  in  storage  units,  and  need  not  be  static.  If  a  static  size 
of  zero  is  specified,  then  no  collection  is  allocated; 
however,  if  a  non-static  size  of  zero  is  specified,  then  the 
default  collection  size  is  allocated. 

Any  attempt  to  allocate  more  objects  than  the  collection  can 
hold  causes  STORAGE_ERROR  to  be  raised.  Dynamically  sized 
records  and  arrays  carry  administrative  overheads  and  must  be 
accounted  for  when  chosing  a  collection  size.  Furthermore, 
for  each  object  allocated  from  a  collection,  there  is  an 
overhead  of  three  words. 

If  no  collection  size  is  specified,  then  the  default 
collection  size  is  used. 

Restrictions  on  Size  Specifications  for  Task  Activation 

The  specification  of  a  task  activation  size  causes  the  task 
activation  to  be  allocated  with  the  specified  size,  expressed 
in  storage  units.  Any  attempt  to  exceed  the  specified  size 
results  in  the  raising  of  STORAGE_ERROR .  If  no  size  is 

given,  then  the  default  task  activation  size  is  used. 

Restrictions  on  Size  Specification  of  'SMALL 

Only  powers  of  two  are  allowed  for  'SMALL.  The  length  of  the 
representation  of  a  type  may  be  effected  by  the  specification 
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of  'SMALL.  If  a  size  specification  is  also  given  for  the 
type,  the  size  specification  takes  precedence;  the  size  of 
•SMALL  must  be  accommodatable  within  the  specified  size. 

Restrictions  on  Enumeration  Representation  Clauses 

Internal  codes  specified  for  enumeration  literals  must  lie 
within  the  range  INTEGER • FIRST. . INTEGER 'LAST.  Note  that 
specification  of  the  internal  codes  or  enumeration  literals 
results  in  significant  runtime  overhead — even  if  the  specified 
codes  match  the  default  values.  (The  default  values  start 
with  zero,  and  increase  by  one  for  each  literal  in  the  list.) 
Thus,  it  is  not  recommended  to  specify  the  internal  codes  for 
enumeration  literals  unless  absolutely  necessary. 

Restrictions  on  Record  Representation  Clauses 

Alignment  clauses  for  record  representation  clauses  are 
observed;  however,  only  power  of  two  values  are  allowed.  The 
specified  alignment  becomes  the  minimum  alignment  of  the 
record  type,  unless  the  minimum  alignment  of  the  record,  as 
determined  by  component  allocation  and  the  minimum  alignment 
requirements  of  those  components  is  more  stringent  than  the 
specified  alignment. 

Component  clauses  are  allowed  only  for  components  and 
discriminants  of  statically  determinable  size.  Not  all 
components  need  be  specified.  Component  clauses  for 
components  of  variant  parts  are  allowed  only  if  the  size  of 
the  record  type  is  determinable  for  every  variant. 

The  size  specified  for  each  component  must  be  sufficient  to 
allocate  all  possible  values  of  the  component  subtype.  The 
location  specified  must  be  compatible  with  any  alignment 
constraints  of  the  component  type.  Alignment  constraints  on 
a  component  type  may  cause  an  implicit  alignment  constraint 
upon  the  containing  record  type. 

If  all  components  and/or  discriminants  are  not  specified  by 
component  clauses,  then  the  unspecified  components 
and  discriminants  are  allocated  after  those  that  are 
specified.  No  attempt  is  made  to  make  use  of  any  gaps  left 
by  the  user-specified  allocation. 

Restrictions  on  Address  Clauses 

Address  clauses  are  supported  with  the  following  restrictions; 


o  The  address  expression  must  be  a  static  expression. 


9 


o  Address  clauses  may  only  be  applied  to  objects  declared 
within  library-level  packages,  and  the  address  clause 
must  be  included  in  the  package  where  the  object  is 
declared.  For  any  other  objects,  address  clauses  are 
ignored. 

o  When  applied  to  an  object,  references  to  the  object 
result  in  direct  references  to  the  exact  location. 

Implementation  Generated  Components  in  Records 

The  only  implementation-generated  components  allocated  within 
records  are  those  generated  for  dope  information  for  arrays 
whose  bounds  are  determined  by  disriminants  of  the  record. 
These  dope  information  components  may  not  be  named  by  the 
user. 

Restrictions  on  Unchecked  Conversions 

The  sizes  of  both  the  source  and  target  types  for  unchecked 
conversions  must  be  known  at  compile  time,  but  they  need  not 
be  the  same  size.  Conversion  to  a  smaller  size  results  in 
truncation,  while  conversion  to  a  larger  size  results  in 
zero-extension.  Calls  on  instantiations  of 

unchecked_conversion  are  automatically  made  inline. 

Implemenation-dependent  Aspects  of  Input-Output  Packages 

The  predefined  packages  DIRECT_IO,  SEQUENTIAL_IO,  and  TEXT_IO, 
as  defined  in  LRM  chapter  14,  are  provided  in  this 
implementation;  package  LOW_LEVEL_IO  is  not.  Because  the 
ZR34325  is  used  in  embedded  applications,  and  because  this 
processor  has  no  input/output  capability,  the  functionality 
of  these  packages  is  limited. 

DIRECT_IO  and  SEQUENTIAL_IO  raise  USE_ERROR  or  NAME_ERROR  if 
a  file  open  or  file  access  is  attempted.  SEQUENTIAL_IO  and 
DIRECT_IO  may  not  be  instantiated  for  unconstrained  array 
types,  nor  for  record  types  with  discriminants  without  default 
values. 

TEXT_IO  supports  reading  from  Standard_Input  and  writing  to 
Standard_Output.  Any  routine  that  takes  a  file  name  raises 
USE_ERROR,  unless  one  of  the  two  aforementioned  standard  files 
is  used;  however,  MODE_ERROR  is  raised  if  the  wrong  one  is 
used. 

Package  MICRO_IO  is  also  provided  to  allow  a  simple  text 
output  capability.  MICRO_IO  allows  output  of  strings.  It 
is  a  small  subset  of  the  functions  available  in  Text  10. 
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Following  is  the  source  listing  of  the  package  specification 
for  MICRO  10. 


-  package  specification  MICR0_I0  *' 

.  *1 


--  Outline;  This  package  contains  a  subset  of  the  specification 

for  Ada  Text  Input-Output  as  described  in  LRN  chapter  U. 

...  ************************************************************************ 

with  PSS_IO_Types;  Use  PSS_IO_Types; 
package  HICRO_IO  is 

subtype  count  is  pss_IO_Types. count.- 

procedure  Put_Line  (I*  '  in  String); 

procedure  Set_Col  .T'-  ;  in  Positive_Count); 

end  MICRO  JO; 


Definition  of  the  Main  Program 

Any  library-level  subprogram  that  has  no  parameters  may  be 
specified  as  the  main  program.  Tasks  initiated  in  library 
units  follow  the  normal  rules  for  termination;  also,  these 
tasks  do  not  terminate  simply  because  the  main  program  has 
terminated.  Thus,  it  is  strongly  recommended  that  terminate 
alternatives  be  provided  in  selective  wait  statements  in 
library-level  tasks. 

Implementation  of  Generics 

All  instantiations  of  generics,  except  for  the  predefined 
generics  UNCHECKED_CONVERSION  and  UNCHECKED_DEALLOCATION  are 
implemented  by  code  duplication. 

The  body  of  a  generic  must  be  compiled  before  the  unit  may  be 
instantiated.  However,  the  specification  and  body  of  a 
generic  need  not  be  included  in  the  same  compilation  unit. 
A  recompilation  of  the  body  of  a  generic  will  make  obsolete 
any  units  which  instantiate  the  generic. 
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Implementation-defined  Characteristics  from  Package  STANDARD 

The  following  are  the  implementation-defined  characteristics 
for  the  Zoran  ZR34325  from  Package  STANDARD  (LRM  Appendix  C)  ; 


type  INTECER  is  range  -8388608  ..  8388607; 
type  FLOAT  is  digits  6  range  -2)W.1111  1111  1111  1111  1111  1111)»£125 
..  2#0.1111J111J111J111J111  lil1#ET25;  “  ”  “ 

type  DURATION  is“delta  0.02  range  -8M00.0  ..  86400.0; 

Attributes  of  Type  DURATION 

The  type  DURATION  has  the  following  attributes  for  the  ZR34325 
target: 


0.015625  seconds 
0.015625  seconds 
-86400.0  seconds 
86400.0  seconds 

Attributes  of  Type  INTEGER 


DURATION 'delta: 
DURATION 'small: 
DURATION'first: 
DURATION' last: 


The  ZR34325  architecture  supports  only  one  predefined  integer 
type,  integer.  Its  attributes  are: 


integer' first 
integer' last: 
integer 'size: 


-(2**23)  or  -8388608 
<2*23)- 1  or  8388607 
24 
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Following  are  the  bounds  of  types  declared  in  TEXT_IO: 


COUNT 'first: 

0 

COUNT' last: 

252 

POSIT IVE_C0UNT' first: 

1 

POSITIVE'cOUNT'last: 

252 

FIELD'first: 

0 

FIELD' last: 

252 

Following  are  the  bounds  of  types  declared  in  DIRECT_IO: 


COUNT 'first:  0 

COUNT 'last:  256 

POSlTlVE_COUNT>first:  1 

POSITIVE”cOUNT'last:  256 


Attributes  of  Type  FLOAT 

The  ZR34325  supports  only  one  predefined  floating  point  type, 
FLOAT.  Notice  that  float 'size  and  float 'mantissa  are  both 
24.  Floating  point  operands  in  the  ZR34325  are  actually  32 
bits;  however,  because  only  the  least  significant  24  bits  of 
any  ZR34325  word  may  be  directly  manipulated,  STORAGE__UNIT  is 
defined  as  24  bits.  If  float 'size  were  defined  as  32  bits, 
two  referable  units  would  be  allocated  for  each  floating  point 
object.  In  order  to  avoid  this,  float 'size  of  24  is  used. 
All  floating  point  objects,  including  floating  point  literals, 
are  allocated  exactly  one  32-bit  target  word  each.  All 
floating  point  operations  assume  native  ZR34325  floating  point 
types.  The  attribute  'SIZE  for  floating  point  types  does  not 
affect  storage  allocation  or  code  generation,  both  of  which 
are  optimized  for  the  machine's  characteristics. 

f loat'size: 
float 'digits: 
float 'mantissa: 
float 'emax: 
f loat'epsilon: 
float'small: 
float 'large: 
f loat'safe_emax: 
f loat'safe_smal I : 
f loat'8afe_large: 
f loat'f irst; 
float' last: 
float  'mach  i  ne_radi  x : 
float' mach i ne^mant i ssa : 
f  I  oat  'mach  i  ne^emax: 
f  loat '  mach  i  ne_emi  n : 
float' mach i ne_rounds : 
float 'machine  overflows: 


24 

6 

21 

S4 

2#1, 

2#1. 

2«1. 

125 

2«1. 

2#1. 

-2«1. 

2»1. 

2 

24 

125 

-125 

TRUE 

TRUE 


0#E-20 

0#E-85 

1111J111_1111J111_1111#E83 

0»E-126 

1111  1111  1111  1111  1111#E124 
llirini  mrilirmi  111#E124 
iiiriiiriiiriiiriiiriiiii(Ei24 
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Package  MACHINE_CODE 

This  implementation  includes  an  implementation  of  package 
MACHINE_CODE .  The  user  should  refer  to  the  listing  of  package 
MACHINE_CODE  included  a  an  appendix  for  further  details. 

The  fundamental  instruction  record  type  is  defined  as  follows: 


type  Z  is 
record 

Operation  :  Op_Code; 
Operands  :  Operand; 
end  record; 


Type  Op_Code  is  defined  in  package  MACHINE_CODE,  and  includes 
all  of  the  ZR34325  opcodes.  Type  Operand  is  a  variant  record 
structure  which  is  used  to  specify  all  other  fields  within  the 
instruction.  It  is  defined  as  follows: 


type  Operand(ot:operand_type:=GEN)  is 
record 
case  ot  is 

when  Addr  »  --  Use  when  you  want  to  set  EMA  field  with  an 

--  Address... (0p_4) 

--  Word  0 

0p_1  :  ten_bits;  •*  bits  16. .25 

0p_2  :  sixteen_bits;  --  bits  0..15 

••  Word  1 

0p_3  :  thirteen_bits;  --  bits  20. .31 

0p_4  :  Zaddr;  --  bits  0..19 
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when  Hit  *»  --  Use  when  you  want  to  include  an  integer  literal 

--  (0p_8) 

--  Word  0 


0p_5  :  ten_bits; 

--  bits 

16.. 25 

0p_6  :  sixteen_bits; 

--  bits 

0..15 

--  Word  1 

0p_7  :  eight  bits; 

--  bits 

24.. 31 

0p“8  :  INTEGER; 

--  bits 

0..23 

when  Flit  =>  --  Use  when  you  want  to  include  a  FLOAT  literal 


--  (OpJI) 


--  Word  0 

0p_9  ; 

ten_bits; 

--  bits 

16.. 25 

Op  jo  : 

sixteen  bits; 

-*  bits 

0..15 

--  Word 

1 

0p_11  : 

FLOAT; 

--  bits 

0..31 

when  Gen 

=>  --  Use  for 

Gen  purpose 

••  Word  0 

Op  12  : 

ten_bits; 

--  bits 

16.. 25 

0p_13  : 

sixteen_bits; 

--  bits 

0..15 

--  Word 

1 

Op  14  ; 

sixteen_bits; 

-•  bits 

16. .31 

OpjS  : 

sixteen_bits; 

-•  bits 

0..15 

end  case; 
end  record; 


All  the  fields  are  set  via  the  actual  bit  values  to  be  used; 
in  other  words,  there  is  no  symbolic  references  possible. 
This  is  a  very  simple  interface,  and  requires  that  the  user 
be  very  careful  when  specifying  instructions. 


Machine-specific  Procedures  (MSPs) 

The  LACE  compiler  includes  two  packages,  ZR34325  MACHINE  and 
ZR34325_MACHINE_DATA,  that  implement  machine-specific 
procedures  (MSPs)  for  the  ZR34325  processor.  These  are 
provided  as  a  set  of  procedure  specifications  that  the  user 
may  call,  which  will  result  in  the  generation  of  one  or  more 
ZR34325  instructions.  To  make  use  of  the  Zoran  MSPs  you  must 
import  both  of  these  packages  via  WITH  clauses. 
ZR34325_MACHINE_DATA  contains  type  and  constant  declarations, 
and  ZR34325_MACHINE  contains  the  actual  MSP  procedure 
specifications. 

It  is  suggested  that  the  prospective  MSP  user  studies  both  of 
these  packages  carefully;  source  listings  of  both  are 
included  as  an  appendix.  In  order  to  make  most  effective  use 
of  the  MSPs,  use  the  constants  defined  in 
ZR34325_MACHINE_DATA,  instead  of  literal  integers,  for  the 
corresponding  MSP  parameters.  These  constants  are  defined 
for  specific  instruction  fields,  which  map  onto  MSP 
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parameters,  and,  in  many  cases,  their  values  have  been  chosen 
to  provide  the  correct  value  to  insert  in  those  fields.  As 
an  example,  the  type  regReference  is  defined  to  cover  the 
range  of  values  that  may  be  specified  for  all  the  register  bit 
fields  of  the  register-based  instructions  (ALO,  LDR,  STR)  . 
The  definition  of  regReference,  and  the  constants  defined  for 
it,  are: 


subtype  regReference  is  integer  range  2.. 262142; 


sun  any  of  the  foUouing: 


rA 

constant 

:* 

128 

rACC_I 

constant 

:= 

8192 

rACC~R 

constant 

:= 

4096 

rB 

constant 

:  = 

64 

rIF 

constant 

:s 

512 

rIM 

constant 

;s 

32768 

rIP 

constant 

:  = 

16384 

rPR 

constant 

:  = 

2 

rLC 

constant 

:  = 

8 

rHBS_MSS 

constant 

;  = 

65536 

rMNMXI 

constant 

:  = 

2048 

rHNMXV 

constant 

:  = 

1024 

r«OOE 

constant 

;3 

131072 

rSAR 

constant 

:  = 

32 

rSP 

constant 

J  3 

16 

rSTATUS 

constant 

256 

rX 

constant 

«s 

4 

Notice  that  all  the  values  are  powers  of  two.  Each  constant 
is  equal  to  the  value  of  the  entire  register  bit  mask  area 
if  only  the  register  for  that  constant  is  set.  Thus,  the 
user  can  specify  multiple  registers  simply  by  adding  the 
register  constants  needed,  such  as  rX+rA+rB+rLC. 

Sample  Program  Using  MSPs 

The  following  is  an  example  of  a  very  simple  program  which 
uses  some  MSPs.  This  program  is  not  intended  to  make  any 
sense;  its  purpose  is  simply  to  show  an  example  of  MSP  usage. 
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Source 


with  system; 

with  MartinGlobal;  --  This  contains  ALPHA.  GAMMA  and  BETA 
use  MartinGlobal; 

with  ZR34325_Machine_0ata; 
use  ZR34325_Hachine_Data; 

with  ZR3432j_tnachine; 
use  ZR3432S_machine; 

procedure  MartinTest  is 
begin 

0RR_LI(16.rM00e); 

OfiR~LI(1,rMOOE); 

L0R~LA( GAMMA ( 0 ] ■ address , rSAR ) ; 

LD_R2<64,ALPHA(0),CO); 

MULT_ER<64,  CO,  8ETA(0),  none,  0,  ACC_use»>replace); 
MULT~ER(64,  CO,  BETA(O),  none,  1,  ACC“use»>replace); 
MULT_ER(64,  CO,  BETA(O),  none,  2,  ACC~use=> rep lace); 
MULT~ER(64,  CO,  BETA<0),  none,  3,  ACC~use=>replace); 

MAX_EX  <  64 , GAMMA ( 0 ) , repeat=>2 ) ; 

SHRRd.rMNMXl); 

end  MartinTest; 
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Generated  code 


AOAMRTNTSTOOOO  EOU  S 


000006  2  31920000  00000010 
000008  2  31920000  00000001 
OOOOOA  2  21E00020  OOOQOQOO  X 
OOOOOC  2  10030040  80100000  X 
OOOOOE  2  B0028080  00000000  X 
000010  2  B0028080  10000000  X 
000012  2  B0028080  20000000  X 
000014  2  B0028080  30000000  X 
000016  2  44028002  80100000  X 
000018  2  31E00800  80100000 

00001 A  2  38000001  06000001 

000000  2  31600010  70000002 
000002  2  21E00020  00000000 
000004  2  24000034  06000003 


ORIGIN  HEX(6) 

ANOR  «0x10,  tSMOOE]  ; 

*  LINE  NUMBER  10. 

ANOR  Mxl,  [SMOOE]  ; 

*  LINE  NIWBER  11. 

LOR  &A0AMRTHLBL000Q«GAMMA«00  =>  CSSARl  ; 

*  LINE  NUMBER  12. 

L0_C:(64)  AOAMRTNLBLOOOO«ALPHA#00:(1,1)  =>  SCO  ; 
•LINE  NUMBER  14. 


MULT_(R,R):(64) 
•LINE  NUMBER  IS. 

SCO. 

A0AMRTNLBL0O0O#BETA#O0:(0.1)  » 

SNULL. 

SACC 

MULT_(R,R):(64) 

•  LINE~NUMBER  16. 

SCO, 

A0AMRTNLBL0O0O#8ETA#O0:(0.2)  => 

SNULL. 

SACC 

MULT_(R,R):(64) 

•  LINE  NUMBER  17. 

SCO. 

A0AMRTNLBL0000#8ETA#O0:(0,4)  => 

SNULL. 

SACC 

MULT_(R,R):<64) 

SCO. 

A0AHRTNLBL0O00#BETA#O0:(0,8)  => 

SNULL. 

SACC 

*  LINE  NUMBER  19. 

MAX_R:(64.2)  AOAMRTNLBL0000#GAMMA#O0: (1 , 1 )  =>  SMNMX  ; 


*  LINE  NUMBER  20. 

SHRR: tSHIFTrl]  [SMNMXI]  ; 

RETURN  EOU  S 

LB..001A  EOU  S 

RET  ; 

ORIGIN  HEX(O) 

SUBR;CTC:1,TR:1]  t*SP3.  #0x2  »>  $X  ; 
LOR  #0x0  s>  CSSAR]  ; 

STR  [SSAR.SSP.SX]  *>  SSP*(3)  ; 

ORIGIN  HEX(IC) 


Interrupt  Processing  Support  Routines 

The  LACE  compiler  includes  the  following  package 
specifications  as  part  of  the  standard,  pre-compile  packages: 


package  OUELL_EXCEPTION  is 
OWELL_EXPIRED  :  exception; 

pragma  L1NKAGE_NAME(0WELL_EXP!RED,  "DWELL  EXPIRED")  ; 
end  DWELL_EXCEPTION; 

with  SYSTEM; 

package  PSS_INTERRUPT_SERVICES  is 
pragma  FORE I GN_BOOY( "ASSEMBLY"); 

procedure  PSS_RECORO_INTERRUPTS  (1NT_MASK  :  integer; 
routine";  SYSTEM. ADDRESS)  ; 

pragma  LINKAGE_NAME<PSS_RECORO_IMTERRUPTS,  "PSS_RECORO_IMTERRUPTS»); 

procedure  PSS_EXCEPTION_INTERRUPTS  (INT_MASK  :  integer)  ; 
pragma  LINKAGE  NAME(PSS~EXCEPTION  INTERRUPTS. 

"PSS_EXCEPT I ON j  NTERRUPtI" ) ; 

end  PSS_INTERRUPT_SERVICES; 
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The  ZR34325  computer  has  one  external  interrupt  that  may  be 
either  an  outgoing  interrupt  (i.e.,  to  signal  another 
processor)  or  an  incoming  interrupt  (i.e.,  so  that  another 
processor  may  signal  the  ZR34325) .  The  enviroment  in  which 
the  LACE  compiler  is  to  be  used  treats  the  external  interrupt 
as  an  incoming  interrupt  that  signals  that  a  processing  dwell 
cycle  has  expired.  When  the  LACE  runtime  interrupt  handler 
processes  the  external  interrupt,  its  normal  action  is  to 
raise  the  exception  DWELL_EXPIRED,  defined  in  package 
DWELL_EXCEPTION,  as  shown  above.  The  user  may  import 
DWELL_EXCEPTION  and  place  handlers  where  needed  to  handle  this 
exception. 

The  user  may  also  import  PSS_INTERRUPT_SERVICES  and  make  calls 
to  the  two  procedures  defined  therein,  PSS_RECORD_INTERRUPTS 
and  PSS_EXCEPTION_INTERRUPTS.  These  procedures  allow  the 
user  to  determine  how  certain  interrupts  are  to  be  processed 
by  the  LACE  runtime  interrupt  handler.  Each  of  these 
procedures  includes  an  integer  input  parameter  called 
INT_MASK.  INT_MASK  is  a  mask  in  which  the  user  specifies 
which  interrupts  are  to  be  affected.  For  bit  positions  zero 
through  twelve  (with  zero  being  the  LSB) ,  each  bit  in  INT_MASK 
specifies  an  interrupt  that  may  be  affected;  a  one  in  that  bit 
position  means  that  the  interrupt  is  to  be  affected,  and  a 
zero  means  that  it  is  not.  Thus,  the  actual  range  of 
meaningful  values  for  INT_MASK  is  1..8191.  Any  other  bit 
positions  that  are  set  in  INT_MASK  are  ignored.  The  following 
is  the  mapping  of  bit  positions  to  ZR34325  interrupts: 

Bit  Interrupt 


0  ISZ  --  Occurs  during  SPLIT  if  DV=1  and  one  of  the 

elements  is  zero. 

1  ISI  --  Invalid  adder  or  subtractor  operation. 

2  ISX  --  Inexact  subtractor  result. 

3  ISU  --  Underflow  in  subtractor. 

4  ISO  --  Overflow  in  subtractor. 

5  lAV  --  Overflow  in  adder. 

6  lAX  --  Inexact  adder  result. 

7  IDO  --  Overflow  in  multiplier. 

8  IDU  -*  Underflow  in  multiplier. 

9  lOX  --  Inexact  result  in  multiplier. 

10  IDI  --  Invalid  multiplier  operation. 

11  IRO  --  Overflow  during  register  operation. 

12  lEI  --  External  interrupt. 

Thus,  a  value  of  3  for  INT_MASK  will  affect  the  ISZ  and  ISI 
interrupts,  while  a  value  of  4096  (16#1000#)  will  affect  the 
lEI  interrupt. 

PSS_RECORD_INTERRUPTS  is  called  to  instruct  the  interrupt 
handler  to  call  the  procedure  specified  by  the  second 
parameter,  ROUTINE,  when  any  of  the  interrupts  identified  in 
INT_MASK  occur.  The  interrupt  handler  will  do  this,  and  when 
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the  procedure  returns  to  the  interrupt  handler,  control  will 
pass  back  to  the  point  of  the  interrupt,  as  if  no  fault  had 
occured.  The  intention  is  to  have  the  procedure  record  that 
the  interrupt  occurred  for  later  evaluation.  The  second 
parameter  to  PSS_RECORD_INTERRUPTS,  ROUTINE  is  of  type 
SYSTEM. ADDRESS;  the  address  of  the  fault-recording  procedure 
should  be  passed  as  this  second  parameter.  The 
fault-recording  procedure  must  have  two  parameters,  the  first 
of  type  SYSTEM. ADDRESS,  and  the  second  of  type  integer. 
When  the  fault-recording  procedure  is  called,  the  first 
parameter  will  contain  the  address  to  which  the  interrupt 
handler  will  return  execution  (and  thus,  very  near  the 
faulting  instruction) ,  and  the  second  parameter  will  contain 
the  value  of  the  interrupt  register  at  the  time  of  the 
interrupt . 


******  Important  notes  ****** 

Fault-recording  procedures  should  not  declare  much  ( if 
any)  local  data,  and  should  not  call  any  other 
subprograms.  This  is  because  they  are  called  using  the 
interrupt  handler's  stack  space,  which  is  ery  limited. 
Furthermore,  processing  should  be  kept  to  a  minimum. 
This  is  because  the  fault-recording  procedures  will 
execute  in  interrupt  mode,  which  is  much  slower  than 
master  mode.  Finally,  if  more  than  one  bit  is  set  in  the 
interrupt  flags  register,  the  one  to  be  processed  is 
selected  as  follows:  First,  all  interrupts  other  than 
the  thirteen  shown  above  are  masked  out.  If  the  external 
iterrupt  has  occured,  it  alone  is  processed.  Otherwise, 
the  signaled  interrupt  with  the  highest  bit  number  from 
the  above  list  is  used  as  the  sole  interrupt  to  be 
processed. 

PSS_EXCEPTION_INTERRUPTS  specifies  that  the  interrupt 
handler  should  raise  an  exception  for  the  interrupts 
specified  by  INT_MASK.  The  external  interrupt,  lEI,  will 
raise  the  DWELL_EXPIRED  interrupt.  All  other  interrupts 
will  raise  NUMERIC_ERROR. 

As  an  example,  if  the  user  wanted  to  specify  that  the  ISO 
interrupt  be  recorded  by  procedure  RECORD_ISO  instead 
of  being  treated  as  an  exception,  then  the  following 
would  be  used: 

procedure  RECORO_tSO  (FAULT_AODRESS  :  SYSTEM. ADDRESS; 

INTERRUPT_FLAGS~ :  integer); 

PSS_REC0RD_INTERRUPTS<16,  REC0RD_1 SO' address); 
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